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В статье строятся онтологии систем, охватывающие различные аспекты системной инженерии, включая 
формулировку требований и спецификаций, архитектурное моделирование, создание рабочего плана, 
тестирование, валидацию и верификацию систем. Особенностью подхода является применение теории 
автоматов для построения онтологической модели процесса разработки систем. Рассматривается 
практическая реализация предложенного подхода в системе ОрепСооКБоок. 


Введение 


Системную инженерию (Зузетз Епотееппе, ЗЕ) можно определить как процесс, 
который преобразует требования и спецификации в функционирующую систему. 
Изначально требования являются нечетко выраженными, так как есть результатом 
взаимодействия множества заинтересованных лиц — разработчиков системы. Иным 
важным аспектом ЗЕ является то, что разработчики выражают требования к будущей 
системе на естественном языке в специфичной для данной предметной области 
(ПрО) терминологии. Ни один из разработчиков не имеет полного представления о 
разрабатываемой системе вне собственной области экспертизы и часто даже не может 
представить, какова будет конечная система в целом. Таким образом, проблемы ЗЕ 
частично обусловлены фактом использования естественного языка и ограниченностью 
области компетентности разработчиков. Путь преодоления этих проблем состоит в 
моделировании и формализации процесса разработки системы. В настоящее время 
для моделирования систем, начальное описание которых осуществляется на естествен- 
ном языке, широкое распространение получили онтологии. По определению Тома 
Грубера, онтологии являются точными, то есть выраженными формальными средствами, 
спецификациями концептуализации [1]. Следуя этому подходу, модель будущей сис- 
темы мы предлагаем рассмотреть как структурированные в виде онтологий описания 
различных аспектов Про. 

Онтологии предоставляют возможность выделения и формализации структуры 
будущей системы, описанной на естественном языке. 

Постановка задачи. Для этого нами предлагается совокупность абстрактных 
концептов и связей между ними, соответствующих различным аспектам ЗЕ. Предла- 
гаемая онтология ЗЕ включает такие базовые понятия, как требование, спецификация, 
архитектура, тестирование, верификация, рабочий план и др. Данные абстрактные 
концепты служат для порождения и структурирования их экземпляров — конкретных 
понятий разрабатываемой системы. 

Цель работы. Иным важным аспектом нашей работы является определение осно- 
ванной на теории автоматов модели процесса ЗЕ. В данном контексте процесс разработки 
системы определяется нами как машина состояний, получаемая путем наложения 
ограничений на переходы между этапами проектирования системы. Например, этап 
архитектурного моделирования может иметь место только после согласования всех 
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спецификаций архитектуры системы. Предложенный подход был практически реали- 
зован в \е-ориентированном инструменте, названном нами ОрепСооКБоокК. 

Статья имеет следующую структуру. Анализ текущих исследований и состо- 
яния проблемы представлен в следующем разделе. Раздел 2 посвящен описанию прин- 
ципов предложенной онтологии и модели процесса ЗЕ. Вводятся понятия абстрактного, 
независимого от ПрО метаонтологического уровня и зависящего от ПрО онтологи- 
ческого уровня понятий. В разделе 3 описывается инструмент, практически осущес- 
твляющий предложенную методологию, а именно, определение и реализацию конкретных 
экземпляров процессов ЗЕ. Приводятся результаты исследований, доказывающие, 
что подход может быть применен к различным ПрО. Завершают нашу статью выводы и 
планы будущих исследований. 


1 Связь с текущими исследованиями 


Предлагаемый нами подход тесно связан с исследованиями, интенсивно прово- 
димыми в других областях системной инженерии, например [2-5]. На сегодняшний 
день существует множество графических средств разработки систем и языков моде- 
лирования, таких как ОМИ [6], [7] и ЗУЗМЕ [6], [8]. Однако заметим, что эти подходы 
страдают от множества недостатков: 

— Существующие подходы претендуют на универсальность, тогда как аспекты 
конкретных систем остаются вне их поля зрения. Для поддержки конкретной ПрО 
(или же класса ПрО) разрабатываются диалекты этих «универсальных» языков, 
служащие для заполнения возникающих «семантических брешей». Однако, в конце 
концов, эти диалекты подрывают полноценность исходной методологии. Именно поэто- 
му мы определяем наш подход как предметно-ориентированный, что позволяет поль- 
зователю самому выбирать систему понятий и связей между ними, а также строить 
модель процесса определения системы. 

— Большинство предлагаемых на рынке инструментов моделирования систем 
есть не что иное, как графический способ представления требований и спецификаций, 
изначально определенных в текстовой форме. Такой подход заставляет разработ- 
чиков думать в контексте предлагаемых графических нотаций и шаблонов разработки, 
что имеет результатом неоптимальные системные решения. Важным аспектом нашего 
подхода является то, что требования и спецификации не содержат в себе архитек- 
турных решений, а также не управляются предопределенными нотациями. 

— Большинство существующих подходов не имеют строгой формальной основы, а 
также опираются на семантически перекрывающиеся базовые понятия. Другими 
словами, существующим подходам недостает ортогональности в определении базовых 
концепций методологий моделирования ПрО. Наш подход изначально подчеркивает 
два аспекта ЗЕ — онтологию системы (отражающую ее структурные, функциональ- 
ные и иные свойства, а также специфичные для ЗЕ требования, спецификации, рабочий 
план и др.) и методологию разработки системы (одним из результатов применения 
которой является модель процесса ЗЕ). 


2 Принципы онтологии и модели процесса 
системной инженерии 


Предлагаемая онтология ЗЕ является системой абстрактных понятий и отно- 
шений между понятиями, предназначенных для структурирования описания системы на 
естественном языке. Предлагаемый поход подход основан на следующих принципах: 

— разграничение интенсиональных и экстенсиональных уровней в описании системы; 
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— различия между онтологиями и метаонтологиями (онтологиями верхнего уровня); 

— построение модели процесса разработки системы; 

— расширение понятия онтологии множеством методов ее использования. 

Раскроем первый принцип. Предлагаемая онтология описывает систему в двух 
ортогональных направлениях: 

1) интенсиональном (уровень намерений, в терминах ЗЕ-требований и специфи- 
каций); 

2) экстенсиональном (уровень расширений, к которому относятся архитектура 
системы и рабочий план по разработке системы). 

Каждый из данных уровней имеет собственный набор понятий и связей между 
ними. Для уровня намерений, например, мы используем понятие спецификация, 
которое имеет отношение «следует» с соответствующим требованием; для архи- 
тектуры системы мы используем понятия сущностей, соединенных взаимодействиями; 
для планирования процесса разработки системы мы используем задачи, соединенные 
отношениями реализации, тестирования, валидации и др. 

Раскроем второй принцип. Для каждой ПрО может быть построена собственная 
онтология, как система понятий и отношений между ними. Эти понятия отражают 
конкретные свойства, структуру, поведение данных ПрО (физических, химических, 
программных, аппаратных и т.д.). Нами выделяют также метаонтологии, которые 
строятся в понятиях, не зависящих от конкретных Про. 

Такой подход сейчас широко развивается в Зетапйс \№еь [9], где онтологии 
подразделяются на предметно-ориентированные онтологии и абстрактные мета- 
онтологии (или же онтологии верхнего уровня), например: 

—ЗОМО (Запдага Оррег Мегоеа Опю]охэу) — стандартная онтология верхнего 
уровня [10]; 

— Зо\а онтология верхнего уровня [11]; 

— Сус’зиррег онтология [12] и др. 

Онтологии верхнего уровня содержат так называемые утверждения здравого 
смысла (соттоп 5еп5е) о ПрО и формируют тем самым единую для онтологий ниж- 
них уровней систему понятий. 

Системная инженерия всегда имеет дело с конкретными Про, однако на более 
высоком уровне абстракции можно выделить понятия, являющиеся инвариантными для 
разных областей, например, объект, отношение, требование, спецификация, задача и т.д. 
Данные понятия связаны отношениями, также инвариантными для множества Про, 
например, часть-целое, экземпляр-класс, причина-следствие и т.д. Такие понятия высо- 
кого уровня абстракции образуют метаонтологию системной инженерии. Данная мета- 
онтология используется нами для порождения онтологий конкретных Про. 

В онтологиях понятия ПрО делятся на классы и индивидуумы (индивиду- 
альные понятия). Предлагаемая нами метаонтология системной инженерии содержит 
классы, которые служат для структурирования конкретных экземпляров (индивидуальных 
понятий) описаний систем. Например, класс «требование» служит обобщением его 
конкретного экземпляра «разгон до 100 км/ч за 6 с». Таким образом, мы используем 
метаонтологию в качестве грамматики для описания системы на естественном языке. 
Понятия и отношения метаонтологии являются общими для ЗЕ и инициализируются 
конкретными экземплярами на уровне определения системы. 

Рассмотрим третий принцип предлагаемого подхода. Отличительной особенностью 
онтологий является формализация связей между понятиями ПрО. Например, отно- 
шения в О\\Т, [13] онтологиях могут иметь свойства транзитивности, функциональности, 
инверсности и др. 
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Мы также помещаем логические условия на отношения понятий метаонтологии 
ЗЕ, однако в нашем случае они определяют изменение состояния системы между 
различными шагами в ее разработке (рис. 1 и 2). Эти изменения состояний и есть 
определение процесса системной инженерии. Иными словами, смысл предложенного 
нами подхода состоит в построении модели процесса ЗЕ на основе конечного автомата, 
где условия отражают переходы состояний в процессе разработки системы. 


АЦ. З!а!и$ 
АБЕ ДлиекА АН. Заи5 
СОИиЦСШ®  Арргоуед и а АКЕ 
[#153 Арргоуеа 
Мо: Аррисаые 


Рисунок 1- Переходы состояний на интенсиональном уровне определения системы 


Метод 


Еп у 
Арргоуе4 


(ЗЧаиз оГ АЦ (Зымиз оГАЦЕ 
А, Зресйсавопз 18 Зресйсай юз 1$ 
ы! Аругоуеа!) АМО (З1аа 
Оемеюртеги Мед оееьия Мепйсаноп аа оГ АЦ. емеюртеи! Манданоп 


(Мепов 1$ Арргоуед АМО 
‘азк Мок Раскаде 13 дейлед) 
ОВ (Мепйсайоп Так 1$ 
Арргоуед) 


(Заз оГ АЦ 
Оеуеюртеп! 
Тазк$ 1$ 
И/ок бопе) 


зазк 


АМО (11/5 оГАЦЕ 
Мопбсабоп Тазкз 15 
Мок бопе) 


Рисунок 2-— Переходы состояний на экстенсиональном уровне определения системы 
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Рисунок 3— Переходы между состояниями системы и понятиями метаонтологии 


Модель процесса ЗЕ определяет, как разработать систему правильным способом. 
На рис. 3 изображены переходы между различными этапами в определении системы. Эти 
этапы в свою очередь являются базовыми концепциями предлагаемой метаонтологии ЗЕ. 

Раскроем последний принцип предлагаемого нами подхода — расширение модели 
онтологии множеством методов ее использования. 
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Онтология О ПрО 4 (от англ. дотат) определяется как набор понятий и отно- 
шений между понятиями О" П (Х, 5%). 


Х={х, |1=1,...,Ё} — конечное множество понятий ПрО. 
= {и |А=Ъ...,К} — конечное множество отношений между понятиями. 


Онтология может также включать иные элементы, например аксиомы, ограничения, 
правила вывода, функции интерпретации и т.д. 

Идея состоит в возможности императивного использования декларативного под- 
хода, который предоставляют онтологии. Данный подход мы осуществляем путем 
добавления в определение онтологии множества методов ее использования М. 

М = {т, |п=1...,М№} — конечное множество методов использования онтологии. 


Таким образом, мы определяем онтологию как: О“ =(Х, 5}, М). 


Приведем примеры методов, применимых к онтологии ЗЕ: 

— метод проектирования системы (определяющий порядок этапов определения 
системы в процессе 5Е); 

— валидация и верификация свойств системы (например, проверка корректности 
вложенности архитектурных элементов системы); 

— стандартизация системы (проверка соответствия некоторым общепринятым 
правилам); 

— генерация архитектуры системы (например, диаграммы классов, в случае пос- 
троения онтологии программной системы); 

— генерация кода программного кода (в случае, когда онтология описывает струк- 
туру программного приложения) и др. 


2.1 Онтология интенсионального уровня 


Рассмотрим подробнее основные понятия и отношения интенсионального уровня 
определения системы. Как было замечено, системная инженерия -— это процесс, ко- 
торый преобразовывает исходные требования в рабочую систему. Первоначально мы 
определяем систему с точки зрения наших намерений. Эта точка зрения и есть интен- 
сиональный уровень определения системы. Следующий уровень — экстенсиональный — 
определяет, как система должна быть реализована (т.е. архитектуру и методы разработки). 

С точки зрения интенсионального уровня система проектируется для того, чтобы 
выполнить все выдвинутые требования. Для этого система декомпозируется на элементы 
(в системной инженерии называемыми также модулями или подсистемами). В пред- 
лагаемой онтологии мы называем элементы сущностями, а способ, которым они связаны 
друг с другом, мы вызываем взаимодействием. Заметим, что каждая сущность может быть 
также отдельной системой; иными словами, понятие сущности является иерархическим. 

Термин «система» используется нами в том случае, когда взаимодействующие 
сущности демонстрируют свойства, которыми они не обладают в отдельности. Например, 
самолет можно определить как систему взаимодействующих сущностей (корпус, крылья, 
шасси и т.д.), которые в отдельности стремятся к падению, однако могут лететь как 
целое. Как сущности и взаимодействия образуют архитектуру системы, так отдельные 
требования формируют предназначение системы в совокупности. 

Мы делаем явное различие между требованиями и спецификациями. Спецификации 
являются измеримыми экземплярами требований и связываются нами с возмож- 
ностью их проверки (путем тестирования, валидации, верификации и других методов). 
Можно иметь несколько систем с общими требованиями, но различными специфи- 
кациями (например, в зависимости от граничных условий, таких как стоимость). Следо- 
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вательно, предпосылкой для проектирования системы (перехода с интенсионального 
на экстенсиональный уровень) являются спецификации, но не требования непосредственно. 

Заметим, что понятия требования и спецификации часто не различаются, и это 
приводит к недоразумениям. Также используется весьма неоднозначное сочетание 
«спецификация требований». В нашем подходе мы используем термин «требование» 
для обозначения желаемых свойств системы. Спецификации являются количественно 
определенными требованиями с ассоциированными методами тестирования и проверки. 

Формулировка требований и спецификаций является самой важной частью 
процесса описания системы. Спецификации порождаются путем конкретизации более 
общих требований и указания процедуры тестирования. Например, изначальное требование 
«автомобиль должен быть быстрым», может быть преобразовано в спецификации 
«ускорение от 0 до 100 км/ч за 6 с» и «достижение максимальной скорости не менее 
200 км/ч». Процедура тестирования в данном случае сводится к измерению величин 
скорости и ускорения. 

Заметим, что спецификации часто формулируются со скрытым предположе- 
нием, что система работает без наблюдаемых или латентных проблем. Мы называем 
такие спецификации нормальными случаями (погта! са5е). Однако этого недостаточно. 
Система соответствует спецификациям только после прохождения тестовых случаев 
(1е51 сазе), описывающих процедуры проверки спецификаций. В соответствии с тесто- 
выми случаями мы определяем случаи отказа (аий сазез), то есть последовательности 
действий, которые могут иметь результатом отказ или некорректное поведение системы. 
Идея состоит в том, что, формулируя случаи отказа, мы начинаем осознавать, что может 
пойти неправильно. Понимание этого прежде реализации системы позволяет преду- 
предить многие возможные бедствия и катастрофы. 

Таким образом, использование онтологии для описания системы на интенсиональ- 
ном уровне позволяет нам создать концептуальную модель из первоначально разрозненных 
и нечетких требований разработчиков. Требования, спецификации, нормальные случаи, 
тесты, случаи отказа есть не просто набор понятий, а концептуальная модель системы со 
структурой, определенной отношениями онтологии. 


2.2 Онтология экстенсионального уровня 


В экстенсиональном или же архитектурном представлении система определя- 
ется сущностями и взаимодействиями между ними. Сущность имеет собственные атри- 
буты и функции. Атрибут является внутренней характеристикой сущности и отражает ее 
качественные и количественные характеристики (например, цвет, скорость, размер и т.д.). 
Атрибуты характеризуются именем, типом и значением. Имя является необходимым 
атрибутом всех сущностей. 

Функции определяют внутреннее поведение сущности в отличие от их внешних 
взаимодействий. Можно указать различные подходы к определению онтологии экстен- 
сионального уровня. Это может быть функциональный, структурный, причинный, собы- 
тийный подходы, рассмотрение системы как машины состояний и др. 

Рассмотрим, например, совокупность понятий онтологии, отражающей событийный 
подход. В этом контексте взаимодействия вызываются событиями и реализуются 
как последовательность сообщений между сущностями системы. Сообщение может 
быть вызвано событием и может также вызывать события. Такой подход имеет широкое 
распространение в моделировании параллельных программных систем, где взаимо- 
действие подразумевает некоторую форму передачи сообщений между объектами. 
Такие сообщения могут использоваться для пересылки данных или же вызывать 
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соответствующие функции внутри программной сущности. Вообще говоря, событием 
может быть любое изменение, имеющее место в системе. Например, событие может 
быть результатом изменения атрибута сущности, влекущего изменение состояния 
всей системы. Мы также предполагаем, что взаимодействие изменяет состояние всех 
участвующих в нем сущностей. 

Иным важным понятием предлагаемой онтологии экстенсионального уровня 
является интерфейс. Интерфейс является точкой взаимодействия между двумя или 
более сущностями. Интерфейсы могут иметь тии вход (три) или выход (ошрий, опре- 
деляющий направление передачи материи, энергии или информации в процессе взаимо- 
действия сущностей. Примеры интерфейсов — электрическая розетка, топливный кон- 
вейер, порт ОЗВ ит.д. 

Интерфейсы необходимы для осуществления взаимодействий между сущностями. 
Интерфейс связывает внешнее взаимодействие с внутренними для сущности функциями. 
Будучи инициатором взаимодействия, интерфейс сущности преобразует внутреннее 
событие во внешнее сообщение. Субъект взаимодействия также получает сообщение 
через собственный интерфейс, преобразовывая внешнее сообщение во внутреннее 
представление (событие). Таким образом, интерфейс фильтрует полученные сообщения 
и вызывает адекватные сущности функции. Пересылка данных в программной системе 
является самым простым примером подобного рода взаимодействий. Заметим также, 
что носитель взаимодействия также является системой со своей собственной структурой. 
Физические, логические и др. свойства носителя также влияют на поведение системы. 
Как пример приведем магистрали Интернета, гидравлические каналы, линии электро- 
передач и т.д. 


2.3 Связь между интенсиональным и экстенсиональным 
уровнями в определении системы 


Как было замечено выше, на интенсиональном уровне система определяется 
требованиями. В дальнейшем требования должны быть преобразованы в экстенсио- 
нальные архитектурные определения, осуществляемые в понятиях сущность, взаимо- 
действие, атрибуты, функции и др. В свою очередь, данные определения ведут к измене- 
нию интенсионального уровня, т.е. уточнению начальных требований и спецификаций. 

Выделение архитектурных атрибутов сущности начинается еще на интенсиональ- 
ном уровне. Например, требование «достижение автомобилем максимальной скорости 
не менее 200 км/ч» декомпозируется в архитектурную сущность («автомобиль»), который 
имеет атрибут типа скорость (определяемый единицей измерения, в данном случае 
«км/ч») с целочисленным значением «200». 

Переход от интенсиональных требований к экстенсиональному архитектурному 
уровню достигается декомпозицией, типификацией, структурированием, определением 
иерархии и другими методами. Качественные интенсиональные требования производят 
экстенсиональные сущности, взаимодействия, интерфейсы, атрибуты, функции, то есть 
архитектурные описания элементов. В свою очередь, архитектура влияет на специ- 
фикации системы (нормальные случаи, тестовые случаи, случаи отказа), план работы, а 
также список нерешенных проблем. Этот порядок действий является существенным 
и задает модель процесса определения системы (рис. 3). 

Заметим, что на интенсиональном этапе процесса проектирования систем еще 
не существует точного архитектурного разложения на сущности и их взаимодействия. 
Существует только незавершенная концептуальная модель, которая выражается в форме 
требований и спецификаций. Задача системного инженера состоит в том, чтобы пре- 
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образовать ее в экстенсиональную форму, то есть разработать архитектурную модель, 
которая будет изоморфной реальной системе. 

В качестве метода перехода с интенсионального на экстенсиональный уровень 
мы предлагаем следующий подход. Во время интенсионального этапа мы выделяем 
номинальные идентификаторы сущностей, которые будут использоваться на экстен- 
сиональном уровне при архитектурном моделировании и планировании работ. Причина 
этого состоит в том, что определение архитектуры на интенсиональном этапе номи- 
нально, то есть мы можем формировать и оперировать только тезаурусом имен сущностей 
и взаимодействий, но не реальной архитектурной моделью. Поэтому данный метод 
можно рассмотреть как первый шаг к переходу от интенсионального к экстенсиональ- 
ному уровню определения системы. 

Интересной проблемой является исследование сущности интенсиональных и 
экстенсиональных отношений между понятиями соответствующих онтологий. Эти 
отношения отличны по своей природе (например, отношение субординации между 
требованиями не подразумевает, что такое подчинение существует между соответ- 
ствующими архитектурными сущностями). Вообще говоря, разработка метода перехода 
от интенсиональной модели требований к экстенсиональной архитектурной модели 
является весьма сложной задачей. Эта проблема сводится к поиску архитектурных 
отношений в интенсиональной модели, отражающих структурные, функциональные, 
временные и иные соотношения реальной системы. 


2.4 Планирование, верификация, тестирование и валидация 


Другой важный аспект процесса системной инженерии — планирование разработки 
проекта, процесс которого в нашем подходе также основан на идентификаторах, явля- 
ющихся результатом архитектурной декомпозиции системы. После идентификации 
сущности группируются в пакеты работ (мотК расказез), которые используются нами 
для планирования проекта. Каждый пакет работ делится на задачи с атрибутами, 
такими, как продолжительность, ресурсы, конечные сроки, ответственные лица и т.д. 
Также рассматриваются запросы на изменение проекта (срапее гедиез15). Некоторые 
задачи связываются не с определенными сущностями, а с методами или стандартами. 
Например, управление версиями — типичное требование методологии для осуществле- 
ния безопасности проекта. 

Определение временной шкалы рабочего плана, включающей такие понятия, как 
пределы, периоды, сроки и т.д., есть важная стадия в разработке системы. Выбор этих 
шкал и связывание их с пакетами работ и задачами является спецификацией рабочего плана. 

Мы различаем следующие классы задач. Задача разработки фактически вклю- 
чает опытно-конструкторские работы, которые также могут содержать другие действия, 
такие как моделирование или формальная проверка системы. Следуя предложенной 
на рис. 3 модели процесса системной инженерии, задача разработки сущности может 
начаться только после одобрения всех связанных с ней спецификаций. 

Верификация определяется нами как процесс проверки не непосредственно 
реализации, а задачи разработки. Ее можно рассмотреть как аудит опытно-конструк- 
торских работ с целью проверки процесса разработки. Верификация должна ответить на 
вопрос «разрабатывали ли мы систему правильно?». В программной инженерии ти- 
пичными примерами верификации является соответствие правилам кодирования, 
управления версиями, нормам проектирования и т.д. Заметим, что верификация может 
иметь место только когда реализация системы была уже осуществлена, хотя она не 
исключает локальные проверки в процессе выполнения работ. Важным аспектом 


«Штучний 1нтелект» 42010 613 


Межуев В.И. 


является то, что верификация должна осуществляться группой инженеров, отличной 
от занимающихся непосредственно разработкой. 

Тестовая задача проверяет (согласно тестовым случаям спецификаций) результаты 
разработки системы. Она осуществляется только после одобрения задачи верификации. 

Наконец мы рассматриваем задачу валидации. Валидация проверяет результат 
реализации (после успешного завершения верификации и тестирования) на соответствие 
начальным требованиям. Валидация должна ответить на вопрос «разработали ли мы 
правильную систему?». Данная проверка направлена «сверху вниз» (т.е. от целостной сис- 
темы к ее частям) и имеет целью интеграцию всех разработанных подсистем. Если вали- 
дация была успешной, продукт может быть «подписан» в реальное производство. Заметим, 
что на данном этапе некоторые свойства системы могут отличаться от тех, что были 
специфицированы изначально. Данный процесс мы называем характеризацией системы. 


3 Разработка прототипа 


Для проверки предложенного подхода и его применимости к различным ПрО 
нами был разработан инструмент ОрепСооКБоок. Первая версия ОрепСооКБооКк была 
основана на Р|опе [14], а следующая на Огира! [15] СМ$ (Сощеп Мапазетепе Зует) 
системах управления содержанием с открытым исходным кодом. Переход на СМ5 
Огира! был сделан нами по причине поддержки таксономии. 

В обоих инструментах новый проект по разработке системы создается как \еБ- 
портал с типами содержания, отражающими предложенную метаонтологию. Инструменты 
ОрепСооКфоок позволяют осуществить связь между различными фазами процесса 
проектирования системы; выполнить проверку онтологии системы на непротиворе- 
чивость и полноту; сгенерировать документы, отражающими текущее описание; осущес- 
твить контроль версий и др. 

Будучи \еБ-инструментом, ОрепСооКфоокК позволяет организовать работу распре- 
деленных команд по определению будущей системы. ОрепСооКфооК поддерживает 
следующие действия пользователей по определению системы, соответствующие пред- 
ложенной модели ЗЕ: 

— выдвижение требований; 

— преобразование требований в спецификации (с определением нормальных, тес- 
товых случаев, а также случаев отказа системы); 

— архитектурную декомпозицию системы на сущности и их взаимодействия; 

— определение пакетов работ и задач (разработки, валидации, верификации, тес- 
тирования). 

Все эти действия поддерживаются общей БД, структура которой отражает пред- 
ложенную метаонтологию ЗЕ. Для тестирования прототипа и проверки его примени- 
мости для различных ПрО нами было проведено множество экспериментов. 

Наиболее важным испытанием прототипа было использование ОрепСооКфоок 
для проектирования операционной системы реального времени ОрепСотКТО$ [16] 
и сопутствующих инструментов. Формальные модели, используемые для разработки 
ОрепСотКТО$, имели очень высокий уровень абстракции, однако этот уровень 
полностью соответствовал предложенной метаонтологии ЗЕ. 

Преимуществом использования ОрепСооКБооК также был инкрементальный 
процесс проектирования ОрепСотКТО$З. Начиная с небольшой и абстрактной модели, 
нами добавлялись все новые детали, пока не появилась модель, близкая к архитек- 
туре реализации. Каждая промежуточная модель подвергалась проверке, что позволяло 
увидеть логические погрешности в проекте. Таким образом, модели разрабатывались 
малыми шагами и подвергались интенсивному анализу всеми членами команды (что 
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обусловлено фактом, что ОрепСооКБоок есть \еБ-инструмент). В результате уровень 
абстракции перешел в конкретную модель реализации. Такой подход также позволил 
нам обнаружить негативное воздействие знания принципов реализации, так как это 
заставляло инженеров думать в понятиях уже созданных ранее систем. Поэтому 
результат проектирования ОрепСотКТОЗ был более точным и имел более компакт- 
ную системную архитектуру. Применение модели процесса параллельно со структурирова- 
нием ПрО посредством онтологий позволило нам гарантировать правильность порядка 
шагов в процессе разработки системы. 

Также наш подход мы сравнили с методом ВРЕ (Визтез$$ Ргосез$ Епошеенпе). 
Как результат мы обнаружили, что наша методология может быть более успешной 
благодаря использованию предметно-ориентированного подхода. Например, технический 
инженер может использовать САО инструменты для моделирования различных сцена- 
риев использования системы; коммерческий директор может создать бизнес-план, 
моделируя бизнес-процесс с использованием финансовой терминологии и т.д. Это отра- 
жает тот факт, что в деловых кругах предназначение системы состоит в том, чтобы 
приносить доход, тогда как в инженерии предназначение системы состоит в обеспе- 
чении определенной функциональности. 

В ходе всех этих экспериментов инструмент ОрепСооКФооКк был усовершенство- 
ван; однако в общем наши исследования доказали применимость предложенного подхода 
для моделирования систем в различных Про. 


Выводы 


В статье предлагается онтология для проектирования систем и основанная на 
ней модель процесса системной инженерии. Модель процесса разработки системы 
строится путем наложения ограничений на этапы определения системы. Таким образом, 
особенность подхода состоит в рассмотрении процесса системной инженерии как 
машины состояний. Предлагаемая онтология ЗЕ предназначена для проверки, разра- 
батываем ли мы правильную систему; модель процесса ЗЕ позволяет проверить, раз- 
рабатываем ли мы систему правильно. Для оценки предложенного подхода был разработан 
у’еБ-ориентированный инструмент ОрепСооКБоок. Была осуществлена поверка при- 
менимости ОрепСооКБооК для моделирования систем из различных предметных областей. 

Наши дальнейшие исследования будут посвящены расширению класса методов, 
применимых к онтологии системной инженерии. Подвергнется формализации и даль- 
нейшему изучению модель процесса ЗЕ, построенная на основе конечного автомата. 
Формализация метода моделирования процесса ЗЕ позволит разработчику создать 
собственный процесс проектирования систем, отражающий особенности конкретной 
организации. Подвергнутся дальнейшей разработке методы перехода между различ- 
ными онтологиями ЗЕ, а также их связь с процессом определения системы. 
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В. Межуев 

Онтолойчн! моделЕ систем та процесу системно! нженерй 

У статт! будуються онтологй систем, що охоплюють р1зн! аспекти системно! 1нженерй, включаючи 
формулювання вимог 1 спецификащй, архтектурне моделювання, створення робочого плану, тестування, 
валлдащю й верифткацию систем. Особлив1стю шдходу е застосування теорй автомат!в для побудови 
онтолог!чно1! модел! процесу розробки систем. Розглядаеться практична реаллзащя запропонованого 
шдходу в 1нструмент! ОрепСооКФоокК. 


Г. Мегйиуеу 

Опююоз1са1 Моде $ о? Зуетз$ апа Зует Епотеегто Ргосе5$ 

ТЬе опю]о21е$ оЁ зу$етаз аге 4еуеоре ш Фе рарег. Те ргорозе опююг1ез епуор уапой$ азрес5 оЁ 
зузет епошеегте, шсаАте сарае тедатетеп5 ап4 зрес1ИсаНопз, агсЬйесвага| подеШипе, стеайоп оЁ 
а у’огК р1ап, {езпе, уаПЧайоп ап уепйсаноп оЁР зузеплз. ТБе Ееавге оЁ арргоасВ 1$ 4еуе]ортепЕ о фе 
опю[о21са| плоде! оЁ зузет епошеегте ргосезз. Ргасйса! паретегшайоп оЁ Фе ргорозе4 арргоасб ш Ше 
ОрепСооКБоок {001 15 сопз14еге4. 


Статья поступила в редакцию 21.06.2010. 
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